Not a fan of the performance/noDelete rule, setting a property to undefined is not equivalent in some cases

e.g.

>  Object.keys({})
[]
>  Object.keys({foo: undefined})
[ 'foo' ]

or when merging objects

> {...{hello: "world"}, ...{}}
{ hello: 'world' }
> {...{hello: "world"}, ...{hello: undefined}}
{ hello: undefined }

sometimes you just wanna get rid of the property altogether

I'm actually a fan of this one. Not having delete makes turbofan optimization much better. We should be paying attention to the usage. I've noticed it when we go from one SSZ container to another and curious if there is a way to update the ssz to ignore undefined fields if they are not part of the container definition...

ssz to ignore undefined fields if they are not part of the container definitio

that's already the case, it only reads fields that are defined in the container, and ignores all others

Not having delete makes turbofan optimization much better

need to carefully review all cases then that are in this PR, afterwards it should be fine, just don't like lint rules that change behavior

Reverted the change for this rule from this PR.

I am in favor of not using delete, but this should be done with more deliberate review in a separate PR.

Let's do it in another PR if this has performance improvements we can take advantage of

this may have unintended consequences... i forget the exact situation but the ssz library was not happy about creating a root (or maybe it was container statics accepting the value, but i forget) when there was an undefined after converting container types...

do we really think this is a good change? Especially for larger code block being explicit with the else seems good to me as it does not rely on if-block to return or throw

Was suggested by @wemeetagain snd I am also in favor of not using such else bocks. More levels of indentations make code less readable.

More levels of indentations make code less readable.

I don't think this can be applied generally, some cases I think identation can help make it more readable

no strong opinions from me. I don't think that this needs to be enforced by the linter.

I would just go with the style that the original author of the code preferred, else is more explicit and can support readability imo.

Doesn't apply everything e.g. sometimes you just wanna throw an error and not use else, if it's a 1-liner

If indentation is needed for readability, one can use code blocks. There is a reason community named such style noUselessElse.

Also if there is larger code block which needs indentation for readability, it should be splited into multiple functions.

I tend to agree with that... else is a code smell of overly long code blocks that could be made more readable...

this may have unintended consequences... i forget the exact situation but the ssz library was not happy about creating a root (or maybe it was container statics accepting the value, but i forget) when there was an undefined after converting container types...